Referring first to FIG. 1, depicted therein is a network-wide view of a typical system for communicating across the Internet 12 between a local system 10 and a target system 14. In such a system, information is transmitted between systems 10 and 14 in the form of data packets sent over the Internet. It has long been known that fragmentation of such data packets by routers 1-N, 24, 26, 30, is generally undesirable. The reason is that such fragmentation and reassembly is an expensive and time consuming process which causes applications to wait until all fragments are received and reassembled. Thus, it is desirable to determine the largest size packet which may be transmitted without being fragmented.
Maximum transfer unit (MTU) of a network interface is defined as the maximum size of the data packet that can be sent out over the network interfaces 16 and 20. Internet 12 is comprised of many networks with different MTUs. Internet traffic usually undergoes fragmentation at the source node and reassembly at the receiving node if the size of the data packet is larger than the MTU of the outgoing interface or the interface of an intermediate router 24-30. However, as already noted, such fragmentation and reassembly is a time consuming and expensive process and causes applications to wait until all fragments are received and reassembled. It is possible to specify that Internet Protocol (IP) data not be fragmented, however this causes IP packets which are larger than the MTUs to be dropped.
Path MTU (PMTU) of an Internet path is defined as the minimum of the MTUs of all of the segments that the path is comprised of. Data fragmentation and reassembly can be avoided if the path MTU of the Internet path between the source and the destination was known. The IETF (Internet Engineering Task Force), which has assumed responsibility for the continued development of the Internet, has published a "Request for Comment" or RFC 1191 which describes a technique for discovering PMTUs of Internet paths by utilizing the "Don't Fragment" (DF) bit in the IP header to discover the PMTU. Setting this DF option in the outgoing data (payload) IP packets enables the sending node to receive an error when the IP packet cannot be sent out because it is larger than the MTU of the outgoing interface and, as a result, the data packet is dropped. The source host 10 initially assumes the PMTU of the path is the known MTU of the first hop, and sends all packets with the DF bit set. If any of the routers 24-30 cannot forward the datagrams without fragmentation, the particular router will discard them and return a "Destination Unreachable, DF set and Fragmentation Required" (Needfrag Error) ICMP message and the source host reduces its assumed PMTU. The PMTU discovery process ends when datagrams are delivered without error or the host may elect to end the discovery process by ceasing to set the DF bit.
While packet drops and data loss were not major issues for classical Internet applications such as mail, FTP, Telnet, etc., they can cause serious quality-of-service (QOS) problems for applications involving multimedia data, such as audio and video teleconferencing, video serving, etc. Data packet drop must be kept to a minimum for such applications, as they may involve real-time data encoding and hence retransmission of a lost or dropped packet may simply not be an option. Therefore, specifying not to fragment IP data may not be useful for multimedia data if there is a need to avoid fragmentation and reassembly for performance reasons.
Previous systems have employed the DF mechanism described in RFC 1191. However, a major flaw in such systems is that the DF bit is sent in actual data. For example, a video server might set the DF bit in accordance with RFC 1191 but only in actual video packets. At least two serious problems arise in so doing. First, in discovering a PMTU, because the DF bit is sent in actual data, failure points in the path may cause actual data packets to be dropped, resulting in lost data. Secondly, again because the DF bit is sent in actual data, it was heretofore impossible to discover the PMTU until the system began transmitting actual data. Yet a further problem of known systems relates to the fact that PMTUs of a path may change over time due to changes in routing topology. Existing PMTU discovery process was ill suited to dynamically detecting changes in PMTU due to the aforementioned route changes.